Prove an attribute using multiple rules

Prove an attribute using multiple rules

A multiply proven attribute is an attribute that appears as the conclusion attribute of more than one rule (including shortcut rules).

An attribute which is proven by multiple rules like this will not function correctly in the Engine because of the operation of the automatic alternate conclusion in every rule. The closed logic of alternative conclusions will prevent multiple rules being traversed - the first rule traversed will close off the possibility of the other forms operating.

What do you want to do?

Intentionally prove an attribute using multiple rules 

Check my rules for multiply proven attributes

Intentionally prove an attribute using multiple rules

The nature of the business rule domain and methodological factors may mean you need to have attributes with multiple, or distributed (non-adjacent), proofs in your rulebase. For such rules it is necessary to designate the rule as a 'rule fragment'. A 'priority' needs to also be specified for these rules to guarantee predictable question searches and inferencing. Lower numbers indicate higher priority (ie priority 1 takes precedence over priority 2 rule fragments).

 

To create rule fragments:

  1. In Microsoft Word, write your rules.
  2. Place the cursor somewhere in the first rule and click the Rule Properties Editor button on the Oracle Policy Modeling toolbar.
  3. Select the Rule Fragment check box.
  4. Specify a priority.
  5. Click OK. Repeat steps 2-5 for each rule.

 

You will notice that your rules in Word are now preceded by a configuration line which indicate that the rule is a rule fragment and shows the priority.

At rulebase build time, rules marked as rule fragments will be automatically combined into a single rule using an inclusive or operator, and will use the author-assigned priorities to determine the question order.

A rule without a proof becomes the default alternative conclusion for the collection of rules if it has a lower priority than the other rules. So, for example, if you wanted to specify an otherwise clause for these rule fragments:

rule_property[fragment:1]

the claimant's queue position = 1 if

the claimant has been queuing longer than anyone else

rule_property[fragment:2]

the claimant's queue position = 1 if

the claimant has jumped to the start of the queue

 

You would need to also have a rule without conditions which specifies the alternative conclusion, ie:

rule_property[fragment:3]

the claimant's queue position = 2

 

Then if the claimant has not been queuing longer than anyone else and has not jumped to the start of the queue, then the result would be that the claimant's queue position is 2.

If this alternative conclusion rule is not provided, the result will be uncertain when the other rules are disproven. That is, if the claimant has not been queuing longer than anyone else and has not jumped to the start of the queue then the result would be uncertain.

Check my rules for multiply proven attributes

Oracle Policy Modeling automatically runs a check for Multiply Proven Attributes when building a rulebase. If any multiple proven attributes are detected, an error will be logged in the Error List and the build will be canceled. To see which attributes are proven by more that one rule, you can generate a Multiply Proven Attributes Report. To do this, select Reports | Multiply Proven Attributes from the main menu in Oracle Policy Modeling.

Attributes that are concluded in rules marked as rule fragments will not fail the Multiply Proven Attributes check at build time, and will not appear in the Multiply Proven Attribute report (unless they are multiply-proven by some other "normal" rule).

The identifying attribute of an entity that is inferred via different relationships will appear in a Multiply Proven Attributes report. Here the identifying attribute is technically multiply-proven because there are multiple rules that cause it to have a value. But the attributes don't actually conflict and aren't problematic, because by definition, if two different values are inferred, then two instances are created and the two values can peacefully co-exist. (However, if another "normal" rule independently inferred the identifying attribute, then there would be a conflict there.)